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ABSTRACT 

The Consultative Committee for Space Data 
Systems (CCSDS) Recommendations for Packet 
Telemetry (PT) and Advanced Orbiting Systems 
(AOS) propose standard solutions to data handling 
problems common to many types of space 
missions. The Recommendations address only 
space/ground and space/space data handling 
systems. Goddard Space Flight Center’s (GSFC’s) 
AOS Testbed (AOST) Program was initiated to 
better understand the Recommendations and their 
impact on real-world systems, and to examine 
the extended domain of ground/ground data 
handling systems. The results and products of the 
Program will reduce the uncertainties associated 
with the development of operational space and 
ground systems that implement the 
Recommendations. 

1. INTRODUCTION 

GSFC s AOST Program continues to provide a 
bridge between the development and widespread 
use of the CCSDS Recommendations. AOST 
Program activities include developing and using 
a Testbed, developing flight-qu alifi able 
components, conducting a test program, 
performing studies, and actively disseminating the 
knowledge gained. This paper presents an 
overview of the Capability Two (C-2) AOST and 
the results and lessons learned through AOST 
Program activities to date (July 1994), including 
architectural issues, the proposed standardized test 
suite, and flight-qualifiable components. This 
paper also summarizes the correlation between 
the AOST and the Code 500 Renaissance effort, 
and AOST future activities, including 
implementation of the Space Communications 
Protocol Standards (SCPS) and the Mission 
Operations Control Architecture (MOCA). 


2. AOST PROGRAM OVERVIEW 

An overview of the C-2 AOST is presented in 
Figure 2.1-1. 


2. 1 FLIGHT SYSTEM ELEMENTS 

The C-2 AOST flight system elements include an 
Instrument Simulator (IS), a Video Digitizer/ 
Packetizer/Multiplexer (VDPM) and a Wideband 
Transfer Frame Formatter (WTFF). These 
elements have been developed by the GSFC 
Instrument Electronic Systems Branch (Code 738). 

The Instrument Simulator creates simulated 
spacecraft instrument data. The IS is capable of 
simulating data for one to six instruments and 
uses the CCSDS Version- 1 Packet format 
(Reference 1). The data generated by the IS are 
input to the WTFF via Fiber Optic Transmitter/ 
Receiver Interfaces (FOXI). 



Figure 2.1-1. C-2 AOST Overview 


1045 


The VDPM generates CCSDS Version- 1 Packets 
and optionally multiplexes them into Multiplexing 
Protocol Data Units (M_PDUs) (Reference 2). The 
Packet data field contains either video data that 
have been converted to digital form by the VDPM 
or octet-aligned digital data input to the VDPM 
via a FOXI interface. The VDPM represents a 
standard interface for CCSDS Path Packet Service. 
The M_PDUs or Version- 1 Packets are input as a 
single data stream to the WTFF using one of seven 
available telemetry user data input interfaces. 

The C-2 WTFF is designed to serve as a gateway 
providing transfer frame generation using PT and 
AOS services for up to seven user virtual channels 
(VCs). Data arriving from any of the seven user 
data input interfaces are buffered and inserted into 
Version 1 Transfer Frames (VlTFs) or Virtual 
Channel Data Units (VCDUs). WTFF processing 
of the data consists of: Reed-Solomon (R-S) 
header, R-S frame, and bit transition density 
encoding; multiplexing of the frames into a single 
physical data stream; and appending of a frame 
synchronization marker to each frame. The WTFF 
also provides the interface to the ground system 
elements. The WTFF can selectably output data 
on one or two physical output channels. 

2.2 GROUND SYSTEM ELEMENTS 

AOST ground system elements include two Front 
Ends (FEs), three types of Service Processors 
(SPs), a Communications Address Processor 
(CAP) and service management elements. The 
CAP provides a connection to a ground 
communications network (GCN). A network and 
service management system controls, configures, 
and monitors the AOST ground system elements. 

The Microelectronics Systems Branch (Code 521) 
is developing the Advanced Front End System 
(AFES), which provides a multiprocessing 
environment based on a VMEbus open 
architecture. The AFES uses cards based on 
custom Very Large Scale Integration (VLSI) 
controllers to achieve a low cost, high speed, and 
highly reliable implementation. Each custom card 
has a 32-bit microprocessor. AFES components 


are being developed for generic applications and 
are being used in other systems such as the Small 
Explorer (SMEX). Commercial off-the-shelf 
(COTS) cards such as Ethernet and Fiber 
Distributed Data Interface (FDDI) cards and disk 
modules are used wherever possible. 

The AFES provides return link processing 
services, configuration management services, and 
testing and verification services. The AFES 
comprises a front end (AFES/FE) and one of the 
SPs, the AFES/SP, housed in a single VME 
enclosure. Frame synchronization, bit transition 
density decoding, R-S header and frame error 
detection and correction, and VC sorting are 
provided by the AFES/FE. The AFES/FE outputs 
data formatted as Space Operations Service Data 
Units (SOSDUs) (Reference 3), a data unit defined 
by the AOST Program. The SOSDU provides a 
mechanism for ground transportation and 
identification of data types consistent with the 
CCSDS Recommendations. The AFES/FE 
transfers SOSDUs to the SPs or to the CAP for 
routing to their user destination(s). The interface 
to the AFES/SP is internal to the AFES; the data 
across this interface are formatted as VC Frame 
SOSDUs. The interface to the ATSPs and to the 
CAP is accomplished using a FDDI LAN. 

The AFES/SP is an integral part of the AFES. 
The AFES/SP performs CCSDS PT and AOS 
processing on the SOSDUs received from the 
AFES/FE, creating Virtual Channel Access 
(VCA), Bitstream, or Path Packet SOSDUs. The 
resulting SOSDUs are transferred to the AFES 
FDDI network interface function for transmission 
to a predetermined destination address. 

Code 521 has also developed a Stand-Alone Front 
End (SAFE) that is identical to the AFES/FE; 
these redundant FE systems enable the AOST to 
process two simultaneous data streams from the 
WTFF. The SAFE also uses FDDI interfaces to 
transfer data to the ATSPs and to the CAP. 

The Data Systems Engineering Branch (Code 564) 
has developed two ATSP implementations using 
solely COTS hardware and operating systems. 
One implementation is using a “Single Board 
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Computer” (ATSP/SBC) and a real-time operating 
system (VxWorks). The second implementation 
is using a SPARC workstation (ATSP/SPARC) 
and a UNIX-based operating system. Both the 
ATSP/SBC and the ATSP/SPARC use Reduced 
Instruction Set Computer (RISC) technology. The 
input, output, and management interfaces are 
identical for both ATSP implementations. The 
ATSPs receive SOSDUs from the AFES/FE or 
the SAFE via the FDDI LAN and process these 
SOSDUs, providing VCA, Bitstream, or Path 
Packet service processing consistent with 
Refeience 2. The goals of the ATSP developments 
are to take advantage of and evaluate the potential 
of the latest technological advancements that 
industry has produced. 

The CAP provides a gateway function for the 
AFES, SAFE, and ATSPs, translating the global 
CCSDS identifiers contained in the SOSDU 
Header to the appropriate user destination 
address(es), and providing protocol translation 
between the AOS Testbed and the GCN. The CAP 
was developed by the NASA Communications 
Division’s Advanced Development Branch (Code 


The GCN provides communications interfaces to 
systems external to the Testbed. 

The Service Management (SM) system developed 
for the AOST allows users of a CCSDS service- 
providing network to interact with that network 
m te rms of services rather than equipment 
configurations. The service management system 
manages equipment configuration information, 
generates periodic reports about the quality of 
services, and monitors ground system elements 
for fault isolation. The AOST SM function 
provides fault detection, isolation, and recovery 
capabilities for CCSDS data services. The MITRE 
Corporation is developing the Network and 
Service Management elements. 

The current management hierarchy for SM 
comprises a Complex Manager that manages the 
AFES, the SAFE, the ATSP/SBC, the ATSP/ 
SPARC, and the CAP. Each managed system 
comprises two conceptual components: the data 


processor, which performs the actual processing 
and presents the agent with a local representation 
of managed parameters; and the agent, which 
translates the management information from the 
local representation to a global representation 
understood by the Complex Manager. The agent 
presents the Complex Manager with a view of 
the processor as a collection of abstract functions 
and system operation parameters. The CAP has 
an agent that is integral to the CAP development* 
the AFES, ATSP/SBC, and ATSP/SPARC have 
SM proxy agents. 


Proxy agents are separate modules that reside on 
the Complex Manager workstation, and are not 
integral to the development of the associated 
ground element. These agents translate the 
Management Information Base (MIB) parameters 
received from the Complex Manager into 
configuration setup tables that are then transmitted 
to the appropriate AOST elements. 


The AOST has developed and tested a 
demonstration version of a standard MIB for 
CCSDS services and protocols (Reference 4). The 
MIB allows the Complex Manager and managed 
systems to exchange management information 
using a common, standard language. The Simple 
Network Management Protocol (SNMP) was 
chosen since it is a well-supported standard 
protocol for managing network elements and 
allows the use of public-domain and COTS 
software for the implementation of the agents and 
Complex Manager. 


3. ACTIVITIES TO DATE 


The C-2 AOST development effort is complete, 
and the testing program for C-2 is nearly complete.’ 

The C-2 AOST provided five CCSDS AOS 
services: VCA service, VC Frame service Path 
Packet service, Bitstream service, and Insert 
service. The C-2 AOST also support a non- 
CCSDS service called Space Link Channel (SLC) 
service. The C-2 AOST supports both 
conventional CCSDS data units, VlTFs, and AOS 
CCSDS data units, VCDUs. 
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A completely new test program was implemented 
for the C-2 AOST (Reference 5). The test program 
implements the Master Test Suite (Reference 6) 
to provide a system-independent series of tests 
that can be implemented to verify any systems’ 
compliance with the CCSDS Recommendations. 

Functional testing associated with the C-2 AOST 
is completed, and research and performance 
testing is in progress. The C-2 program has 
produced a number of results, some related to 
implementation issues associated with the 
development of AOST elements, and others 
related to the CCSDS Recommendations 
themselves. A selection of these results are 
presented in Section 4. 

Flight-qualifiable components have been produced 
from the equipment in the AOST and additional 
flight-qualifiable components are currently being 
manufactured. 

A library of AOST Program and related 
documents continues to serve as a central 
repository of knowledge gained and products for 
the AOST Program. A second AOST Workshop 
has been scheduled for November 1994 to 
disseminate AOST results. 

4. RESULTS 

4.1 ARCHITECTURE 

4.1.1 Service & Network Management 

AOST SM has greatly facilitated the operation of 
the AOST ground elements, and has streamlined 
the testing and analysis process within the Testbed. 
SM controls, configures, and monitors all Testbed 
ground elements from a single workstation, 
providing a focus for AOST ground system 
activity. The SM graphical user interface allows 
the operator to highlight AOST elements, select 
predefined configurations, create new 
configurations, and download these configurations 
to appropriate AOST element(s). SM is also able 
monitor the results of data processing by obtaining 
status information from each element either on 


demand or on a periodic basis. These status data 
can be displayed in real-time either numerically 
or in graphical format; periodic data can be 
graphed over time to monitor data processing 
history. 

The AOST SM mitigates sources of error in the 
comprehensive configuration of the AOST by 
centralizing and streamlining configuration and 
control. The service-level specifications 
manipulated at the Complex Manager workstation 
concisely define the comprehensive Testbed 
configuration, and mitigate configuration errors 
often experienced in the past when local system- 
level configurations were used. The simultaneous 
configuration and coordination of several Testbed 
elements via SM has reduced the number of 
configuration mismatches, and has allowed for 
spontaneous development of new scenarios and 
what-if analyses. 

By acquiring and displaying status information 
from multiple ground elements simultaneously, 
SM expedites the analysis of AOST data 
processing activities. The ability to display and 
graph data from multiple sources in near-real time 
has been an invaluable tool to developing a 
comprehensive view of AOST data processing 
activities. SM also maintains log files that permit 
more comprehensive post-test analysis. 

One of the issues related to the development of 
SM was the coordination of the proxy agent 
development with that of the data processors. It 
was necessary to maintain a constant dialog 
between the proxy agent developer and the data 
processor developer during the development 
process to ensure that the system-level 
configurations performed by the proxy agent 
matched the system-level specification within the 
data processor. On several occasions, small 
software changes were made to a data processor 
that required corresponding changes to the 
configurations being managed by the proxy agent. 
SM functionality is predicated on a successful 
communication process to coordinate agent- 
system interaction. 
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In the next version of the AOST, the Testbed 
may develop a Network Management Integration 
and Coordination workstation that manages a set 
of Complex Managers. Also, SM may be extended 
to flight elements, either via a direct link or across 
a ground-space forward link. 

4. 1 .2 Data Latency 

The AOST has been addressing latency issues 
associated with the AOST elements and the 
interfaces between the AOST elements. Low data 
latency is desirable, constant data latency is 
required, and data loss is unacceptable. The AOST 
test program is currently attempting to vary the 
transmission approach across the LANs in the 
AOST to best meet these three criteria. The AOST 
is being subjected to a series of performance tests 
designed to measure and improve data throughput. 
A FDDI LAN analyzer is being employed to assist 
in the analysis of the FDDI LAN components 
and AOST elements. 

Data losses have been experienced on the FDDI 
LANs used to transmit data between AOST 
ground elements. The AOST test program is 
currently investigating these data losses, 
employing strategies to analyze and eliminate 
these data losses. 

The FDDI LAN packet size in use for the AOST 
is predetermined to be 4136 octets in length, with 
4096 octets dedicated to data. A ground rule 
established for AOST regarding the FDDI LANs 
and designed to facilitate low data latency was 
that a single FDDI packet would contain no more 
than one SOSDU. With the exception of Path 
Packet SOSDUs (which vary in length in 
proportion to the packet length) the length of all 
the SOSDU data types handled by the AOST are 
significantly shorter than the FDDI LAN packet 
length. Non-Path Packet SOSDUs use no more 
than 32% of the FDDI LAN packet capacity. 

The AOST will “pack” SOSDUs into FDDI 
packets in an attempt to increase the effective 


FDDI LAN utilization. The challenge is to ensure 
low data latency and data delivery without 
substantially compromising constant data latency. 
Once hardware and software modifications are 
made to effect this change in FDDI LAN 
utilization, tests will be conducted to measure the 
resulting data latencies and the data throughput 
capability. 

Future ground systems that transport data 
consistent with the CCSDS Recommendations 
should consider data transmission methodologies 
that better facilitate the rapid transfer of variable- 
length data units. For example, the use of variable- 
length FDDI LAN packets that more closely 
accommodate the varying SOSDU sizes would 
improve AOST FDDI LAN utilization while 
maintaining constant and low data latencies. The 
equipment currently in use in the AOST does not 
facilitate using variable FDDI LAN packets. 


4. 1 .3 Data Distribution 

Equipment designed to support data processing 
consistent with the CCSDS Recommendations 
should manage and control each VC data stream 
separately. As built, AOST ground elements do 
not always regard each VC as a separate channel, 
limiting data management and distribution 
capabilities. Furthermore, the inability to manage 
each VC separately impacts other ground elements 
in the Testbed. 

The CAP was implemented within the AOST to 
route data, based on VC, to destinations outside 
the AOST. The CAP is the only AOST ground 
element that can route data to multiple output 
destinations by VC. During the C-2 design phase, 
a decision was made to route the output of the 
AOST FEs and SPs to a single destination by 
Internet Protocol address. The implementation of 
testing scenarios has been limited by the inability 
to route data between the AOST ground system 
elements by VC. For example, scenarios were 
developed to use separate service processors to 
process different VCs emanating from a single 
front end system. It was not possible to selectively 
route data from a single front end to more than 
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one service processor. To implement this scenario, 
the front end system was set to “broadcast” data, 
that is, send all the data to all the active service 
processors. While introducing obvious security 
concerns, data broadcasting forces each service 
processors to examine each incoming data unit to 
determine if it should be processed. A service 
processor not designed to perform this query as 
the initial data processing step will suffer certain 
performance degradation as it partially processes 
data before rejecting it. 

A fundamental change in the approach toward 
data transmission is being instituted in the AOST 
to enable each AOST front end system to transmit 
each VC data stream to a separate destination. 
The extra processing required to route each VC 
to a specific destination will have some effect on 
the performance of the front end processors, but 
should result in better service processing 
performance. Implementation and testing are 
necessary to determine the aggregate AOST 
performance improvement. 

4. 1 .4 Interactive Determination of 
Grade of Service 

In an attempt to achieve a more “data driven” 
system (Reference 7), the C-2 AOST was prepared 
to implement the dynamic model given in the 
“AOS Green Book” (Reference 8), section A.4.1, 
Option-B, for determining Grade of Service. 
Figure 4.1-1 presents a flowchart representing the 
referenced algorithm. The AOST has identified 
three issues associated with the interactive 
determination of Grade of Service. The first issue 
is related to R-S header decoding (Grade 3), the 
second related to R-S frame decoding (Grade 2) 
when the data zone is populated with an octet- 
repetitive data pattern, and the third is related to 
performing R-S decoding on a VC basis. 

4. 1.4.1 R-S Header Decoding IGrade 31 

The algorithm illustrated in Figure 4.1-1 initially 
attempts to perform R-S frame decoding; the 
presence of the R-S header encoding and CRC 
fields are not considered in this portion of the 


algorithm. If the frame fails R-S frame decoding, 
R-S header decoding is then attempted. There is 
a 31% chance that a frame that is not R-S header 
encoded will pass R-S header decoding with two 
“correctable” errors (see R-S (10,6) Header 
Decoding Analysis , next page). When the frame 
is falsely identified as being R-S header encoded, 
the “errors” are corrected changing values in the 
header. The changed header values can result in 
misidentification and misrouting of the frame. As 
the algorithm checks for R-S header encoding 
only after R-S frame encoding has failed, the 
actual probability of a frame being altered due to 
false determination of the presence of R-S header 
encoding is 0.31 (probability of an uncorrectable 
R-S frame encoded VCDU). 

The AOS Green Book, section A.4.1, Option-A 
specifies a dynamic model for determining Grade 
of Service in which header decoding is performed 
first. Using this same analysis, there is a 31% 
chance that a frame that is not R-S header encoded 
will pass R-S header decoding with two 
“correctable” errors when Option-A is 
implemented. 


VCDU/CVCDU 

In 



Figure 4.1-1. Option-B Error Control Decoding 
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4. 1.4.2 (255. 223) R-S Frame Decoding of 
Octet-Repetitive Data Zone Patterns 

The data used in the AOST is usually simulated 
data that contains octet-repetitive data patterns in 
the data zone portions of the packets and frames, 
e.g., the data zone of a frame would be populated 
with “A5A5A5A5A5A5...” (hexadecimal). Tests 
reveal that a frame containing a high percentage 
of octet-repetitive data patterns will be decoded 
and “corrected” when the dynamic model for R-S 
decoding is applied using the (255,223) R-S code, 
whether or not the VCDU is R-S frame encoded. 
An invalid correction can alter header values 
resulting in misidentification and misrouting of 
the frame. 


R-S (10,6) Header Decoding Analysis 

CCSDS R-S encoded headers consist of 3 
octets of header data and 2 octets of parity. 
The code can correct up to 2 errors in the 5 
octet pattern. Since parity is derived from the 
3 octets of header data, there are 2 (8)(3) = 2 24 
possible codewords, and 2 (8)(5) - 2 40 possible 5 
octet patterns. Since parity of the R-S (10,6) 
code is 2 octets in length, a 5 octet pattern has 
a l/2 &m ~ 2 : * probability of being a codeword 
with no error. 

I The R-S (10,6) code operates on 4 bit 
; “nibbles '; for a 5 octet pattern, there are 10 
; nibbles. For each nibble, there is I correct value 
I and 15 possible incorrect values. The code will 
correct for any of the 15 possible error patterns 
in any one of the 10 nibbles. Therefore, there 
are t o x 10 = 150 possible single error cases 
1 that will be corrected for each codeword. 

j A 5 octet pattern has a 1 50 x 2' ■ 6 ~ 0.0023 
\ probability of being a codeword with one 
i correctable error. 

The code will also correct for any of the 1 5 
possible error patterns in any one of the other 
9 nibbles lor each of the 150 single error cases. 
Therefore, there tire 150 x 9 x 15 ~ 20,250 
double error cases that will he decoded 
correctly for each codeword. A 5-octet data 
pattern has a 20,250 x 2"** ~ 0,309 probability 
ot being a codeword with two correctable errors. 


The source of this invalid correction is the fact 
that 255 octets containing octet-repetitive data 
represent a valid R-S codeword. Thus, if any set 
of 255 octets has 239 or more octets that are 
repetitive, a R-S frame decoder will “correct” the 
set to have 255 repetitive octets. A R-S header 
encoded VCDU with an octet-repetitive data zone 
will contain only 10 octets not equal to the data 
zone octets. The following 10 octets will be 
corrected to match the repetitive octet pattern: 

• frame primary header - 6 octets 

• header parity - 2 octets 

• frame CRC - 2 octets 

For a VCDU of Interleave 5 containing CCSDS 
Version 1 Packets, the R-S frame decoder will 
“correct” the frame first header pointer (2 octets) 
and the packet primary header (6 octets per packet) 
for up to 6 packets in the frame data zone, 
assuming all the packet source data zones share 
the same octet-repetitive data pattern. 

4. 1.4.3 R-S Decoding hv VC 

The AOS Blue Book (Reference 2), paragraph 
5.4.9. 2. 1.5. a states, “The presence or absence of 
[R-S frame encoding] is an attribute of the Virtual 
Channel and is pre-specified by management.” 
The system performing R-S decoding and 
correction must look at the VC to determining 
whether to perform R-S header or R-S frame 
decoding. Prior to decoding, the value in the VC 
field is potentially erroneous and is therefore not 
a reliable value upon which to base Grade of 
Service determination. 

4- 1 -4.4 R-S Decoding Conclusions 

The AOST has addressed these three issues by 
prespecifying a Grade of Service for the entire 
physical channel, and limiting the physical channel 
to a single Grade of Service. This approach 
resolves the issues associated with R-S 
specification per VC, and the potentially erroneous 
decoding of both R-S headers and R-S frames 
associated with “on-the-fly” Grade of Service 
determination. While prespecifying a Grade of 
Service for a physical channel is a compromise 
of the Recommendations, it is currently the only 
reliable alternative presently identified. 
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4.2 TEST SUITE 

The Master Test Suite (MTS) for New AOS 
Implementations, (Reference 6) has been used to 
implement the tests for the C-2 AOST Test Plan 
(Reference 5). The functional test cases used for 
C-2 testing have a one-to-one correspondence to 
the tests identified in the MTS, and the structure 
of each test case is as close to the specifications 
in the MTS as possible. 

There was no single AOST data generator that 
could implement the entire MTS. A combination 
of the C-2 AOST flight elements and a data 
simulation tool developed by Code 521, the Test 
Pattern Generator (TPGEN), were used to 
implement portions of the MTS for the C-2 AOST. 
A portion of the MTS could not be implemented 
by any test tool available in the AOST; the error 
patterns identified in some of the MTS test cases 
could not be created. The next iteration of the 
AOST may provide a test tool based on TPGEN 
that provides the full complement of tests in the 
MTS. 

The portion of the MTS that was implemented 
provided a rigorous and thorough test of the 
functionality of AOST elements. The AOST data 
generators did not always provide a sufficient 
amount of data, however. Some problems with 
functional production occurred when the systems 
were tested with large data volumes, for longer 
periods of time, from a few minutes to 24 hours, 
and at higher data rates. Systems that successfully 
passed functional tests with brief test data sets, 
composed of only a few hundred frames each 
and processed within 1 to 5 seconds, developed 
anomalies after processing more continuous data 
sets and/or data transmitted at a higher data rate. 
An analysis of the test cases identified in the MTS 
will be performed to ensure that each test case 
requires a sufficient amount of data. 

The MTS defines tests to be implemented at the 
system module level. For example, the test case 
for frame synchronization tests only the part of 
the system that performs frame synchronization. 
The MTS approach of testing system modules is 


analogous to the testing performed by a 
programmer during integration and development. 
The C-2 AOST Test Program is analogous to an 
independent system verification and validation. 
The C-2 Test Program provided at least one data 
set to test each function identified in the MTS. 

Providing one data set to test each function 
identified in the MTS created significant 
redundancy in the complement of tests. For 
instance, the first test performed, frame 
synchronization, also succeeded in testing 
processing for R-S header decoding, CRC 
decoding, and VC Frame creation. Some 
streamlining of the MTS is appropriate when 
testing is performed at the system level. The next 
iteration of the MTS may provide a streamlined 
set of test cases for testing performed at the system 
level. 

4.3 FLIGHT-QUALIFIABLE COMPONENTS 

Two CCSDS-based and one non-CCSDS flight- 
qualified components are being developed: 

• Reed-Solomon Encoder 

• Reed-Solomon Decoder 

• Lossless Data Compressor 

The flight-qualified R-S Encoder features a 
selectable interleave depth (1 to 8) and supports a 
sustained data rate of 200 Mbps. This Encoder is 
currently available for flight project use, and has 
been delivered to the Tropical Rainfall Measuring 
Mission and the X-ray Timing Experiment. 

The flight qualifiable R-S Decoder is designed 
and currently scheduled for production at the 
NASA Microelectronics Research Center at the 
University of New Mexico. This chip will perform 
1 to 16 symbol error corrections at a sustained 
data rate of 150 Mbps. The flight qualifiable R-S 
Decoder will incorporate technology allowing the 
production of flight-qualifiable components by a 
commercial foundry. 
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The flight-qualified lossless data compressor has 
been developed and manufactured. This 
compressor chip is available for flight project use, 
and has been delivered for use on Landsat 7. 

4.4 KNOWLEDGE TRANSFER 

The knowledge gained through the AOST 
Program is disseminated to a wide audience that 
includes flight projects, users, and ground system 
developers, among others. Workshops provide a 
forum for the exchange of knowledge between 
AOST participants and other interested 
organizations. A library and knowledge database 
have also been created. An AOST workshop is 
scheduled for November 1994. 

4.5 AOST AND RENAISSANCE 

The GSFC Code 500 Renaissance effort is an 
approach to data systems development designed 
to improve quality and lower development life 
cycle cost through the implementation of 
standards, modularity, and reusable components 
(building blocks) supporting varying classes of 
missions and complexity. 

Should the Renaissance effort chose to implement 
a Testbed for the prototyping of building blocks, 
the AOST architectural approach is a effective 
model. The concept of well defined functional 
building blocks on a distributed communications 
network that supports commercial protocols is 
central to both the AOST and Renaissance. The 
redundant front end processors are developed from 
a set of Code 52 1 modular components. The front 
end processors used in the AOST are easily 
reproducible from both COTS and custom 
components. Two of the service processors 
developed in the AOST are also software based; 
one is developed using the C programming 
language on a UNIX platform, making it easily 
transportable to a large number of commercial 
workstations. The FDDI LAN connecting the 
AOST ground system elements can incorporate 


other components developed either within or 
external to the AOST. The AOST has the potential 
to easily incorporate and/or test new components. 

5. AOST FUTURE PLANS 

The next iteration of the AOST, Capability Three 
(C-3) will incorporate a forward link capability 
to demonstrate, validate, and verify future 
implementations of the CCSDS Telecommand 
(TC) and AOS (forward link) Recommendations. 
Specifically, the forward link capability will be 
designed to support the SCPS and MOCA. 
Implementation of the TC and AOS 
Recommendations, SCPS, and MOCA will 
necessarily be incremental, since SCPS depends 
on the underlying Layer 1 and 2 services provided 
by the CCSDS Recommendations, and MOCA 
depends on the upper layer services provided by 
SCPS. The incorporation of the forward link will 
require the addition of new ground elements to 
the AOST, as well as enhancing existing ground 
and flight elements. 


6. SUMMARY 

The AOST continues to provide a key source of 
findings and information related to the 
implementation of the CCSDS Recommendations. 
The AOST work will continue through 1995 with 
a Testbed that supports the AOS and TC forward 
link command and uplink data generation and 
processing, SCPS, and MOCA. The AOST 
remains available to support testing of flight 
elements and ground system data processors. 
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